A service data flow is normally identified by techniques such as Internet Protocol 5-tuple inspection or by using Deep Packet Inspection based on e.g. Uniform Resource Location inspection. Methods for assigning a priority level or Quality of Service for such service data flows are well known. For instance, in 3rd Generation Partnership Project networks, a service data flow can be associated with a, so called, dedicated bearer, to which all traffic belonging to the service data flow is mapped. Identification of service data flows can also be used to trigger upgrades of the priority of an existing bearer or data channel. This is all well known.
Common to these two cases is that an appropriate priority level typically has to be associated with the dedicated or upgraded bearer. The priority level may for instance be implemented by using a “scheduling weight” or similar priority parameter in the scheduler in the base stations of mobile broadband networks.
Whereas a high priority or aggressive scheduling weight provides the best effect of prioritization, it also has the highest impact on traffic of other users in the cell.
For short-lived service data flows, where a short response time for a user is desirable, a high priority may be acceptable. This is due to that the volume of the data being aggregated by the service data flow is also low and therefore the impact on the performance of traffic from other users in the system is negligible.
For long-lived service data flows having a large data volume being transmitted, such as when downloading large data files, the benefits of a high priority are less emphasized, as only a moderate priority level increase will give a significant improvement in the download time. Transferring large data volumes using a high priority can have considerable negative impact on the performance of other. Therefore, for large data volumes, the usage of a moderate priority level is often more desirable, where the moderate priority level is lower than a “high” priority level, but however still higher than a default priority level.
To make a right choice, i.e. what level of prioritization to use for a service data flow, the service data flow has to be characterized to some extent. In many cases the identification techniques as described above, IP 5-tuple and Deep Packet Inspection, are fully adequate and sufficient for this characterization.
However, there are conditions at which the aforementioned techniques are not sufficient and that is when multiple service data flows are multiplexed into a single service data flow one, which makes the original service data flows indistinguishable from each other.
One example is optimization client/proxy multiplexing of service data flows into a single compressed data stream, for which to intermediate systems the service data flows will appear as a single service data flow. Another example is Virtual Private Network tunnels, e.g. clients connecting to enterprise networks using Secure Sockets Layer or IP Security Virtual Private Networks. Other examples are long-lived secure Hyper Text Transfer Protocol sessions which support interactivity with the clients, as well as SPDY protocol sessions over Secure Sockets Layer/Transport Layer Security.
A characterization of a multiplexed service data flow would only detect a single service data flow. This service data flow would then comprise several micro flows, potentially with very different characteristics. These micro flows are however not easily identifiable using conventional methods.
Common to these cases is that it is now intrinsically difficult to characterize the service data flow such that an appropriate prioritization level can be chosen. To mitigate the cost penalties that would arise from choosing too high a priority level, a more moderate priority level will likely have to be chosen. However, the result of a more moderate priority level is that the short lived micro flows will not benefit from the higher priority level that they would otherwise have received.
As a measure to adopt a priority level a leaky bucket-type algorithm has been used in quality of service contexts. According to the typical use however is to perform actions on non-conformant data traffic, e.g. any data traffic exceeding say 100 kbps will be sent at a lower priority, or even be dropped.
There is thus a need for an alternative approach by which a prioritization level can be successfully determined for a service data flow having unknown characteristics.